[レポート]Dr.Werner VogelsのKeynoteより-AWSの仮想化環境の進化の歴史 #reinvent

[レポート]Dr.Werner VogelsのKeynoteより-AWSの仮想化環境の進化の歴史 #reinvent

Clock Icon2019.12.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

オペレーション部 江口です。 re:InventのKeynote2日目はDr.Werner Vogelsの講演でした。 その講演の中では、AWSが新しい仮想化環境「AWS Nitro System」をどのように進化させてきたのか、その歴史を紐解いていきました。

個人的に興味深いトピックだったので、Keynoteからこの部分を抜粋して紹介したいと思います。

なおVogels氏のKeynoteはYoutubeですでに配信されていますので、ご興味ある方はご確認ください。

講演内容

クラシックな仮想環境の課題と、AWSの新しい仮想環境へのアプローチ

  • クラシックな仮想化環境では、I/OをゲストOS同士が取り合うことが課題だった
    • 特にNWリソースについては顕著で、ジッタやレイテンシが発生することになる
    • どうすれば仮想化サーバでもベアメタルサーバ同様のパフォーマンスを顧客に提供できるかをAWSは考えた

  • 伝統的な仮想化の世界はモノリス
    • (筐体内の)全てのHWコンポーネントが同じハイパーバイザによって管理されている
  • AWSは新しい仮想化のアーキテクチャとしてマイクロサービスのアプローチをアーキテクチャに持ち込んだ
    • マイクロサービスのようにハードウェア同士がPCIバスを通してAPIでつながる(ハードウェアAPI)

AWSによる新しい仮想環境(Nitro)の実装のステップ

  • Step1: まずネットワークコンポーネントを別カードに移し、処理をオフロードした(2013年ローンチのc3インスタンス)

  • Step2: 次にEBSの処理を別カードに移した(c4インスタンス)。これによりメインCPUをゲストOSのネットワーク、ストレージのIOの処理に割かずに済むようになった

  • Step3: 残っていたローカルストレージなど全てのIOを別カードに移行(c5インスタンス)

  • Step4: ハイパーバイザの残りの全てのピースをコントロールプレーン上の各カードに移動。これでNitro Systemが一通り完成した。同時に非常に小さい、新しいハイパーバイザを開発

Nitro Systemでの処理の流れ(EBSのボリュームアタッチする場合を例に説明)

  • EBSのボリュームをアタッチする場合、まずEBSコントロールプレーンに要求をする
  • EBSコントロールプレーンはNitroシステム内のEBSのカードとコミュニケーションする
  • EBSカードはNVMeデバイス上でボリュームの作成を行い、PCIバスで通知を行う
  • 上記の通知をハイパーバイザがトラップ、実際のマウントを行う

  • 結果としてジッターが大きく低減し、IOPSは倍増した
    • c5インスタンスのストレージのレイテンシはベアメタルなみ

セキュリティの強化 - Trust no one:kill Dom0

注)Dom0(Domain 0)・・・Xenハイパーバイザの管理用ゲストOS。ハイパーバイザが起動する時に自動的に実行され、特別な管理特権と、全ての物理ハードウェアへの直接アクセスを受け持つ。

  • Dom0はLinuxインスタンスで、ユーザはログインが可能でメモリダンプなどを行えてしまう
  • このためDom0はセキュリティリスクが高い
  • そのためNitro SystemではDom0を無くした。
  • Dom0を無くすことにより、どこからも(管理用に)SSHすることはできなくなり、よりセキュアな環境となる

Nitro Systemでのコミュニケーションフローの管理

  • Nitro Systemでは、各コンポーネントがコミュニケーションを行なってリソースの操作などを行うが、セキュリティのためこのフローも管理されている
  • Nitroコントローラはハイパーバイザに対してコミュニケーションすることができる。しかし、ハイパーバイザからコントローラへ書き込みを行うことはできない
    • このため例えハイパーバイザに侵入されても、コントローラに対して操作を行えない
  • 同様に外部コントロールプレーンとNitroコントローラもコミュニケーションできるが、Nitroコントローラに対して書き込みを行うことはできない

Nitro Systemでの暗号化

  • Nitro Systemでは、Nitroカードの外のコミュニケーションは全てデフォルトで暗号化されている
  • ネットワークだけでなく、ローカルディスクもデフォルトで暗号化
  • ホストもゲストも信頼せず、ハードウェアに対し操作を行おうとしていないかを確認する
  • ハードウェアが起動した際も、不揮発性メモリなどを調べ、どのコンポーネントにも侵入されていないかを最初に確認する。不審な機器については調査を行う

Nitro Systemにより実現できるようになったこと

  • このNitro Systemsという新しいプラットフォームを作ったことで、さまざまなことができるようになった
    • ハイパーバイザからNitroカードに対して、システムをダウンさせることなくパッチを当てるLive update
    • 別のハイパーバイザのシステムへの追加(※「VMware」のロゴが出ていたので Cloud on AWSのことを指していると思われます)
    • ベアメタルサーバのシステムへの追加
    • Outpostsの制作

  • さらに、センシティブなデータを保護するサービスであるNitro Enclavesをリリースする

※ Enclavesの詳細は以下のブログ記事をご参照ください。

[速報] EC2インスタンスで高機密性のデータ保護が可能となるAWS Nitro Enclavesのプレビュー申し込みが開始! #reinvent

終わりに

以上、Dr.Werner VogelsのKeynoteからNitroの進化の歴史についての話のみ抜粋してみました。書き起こすと長く見えますが、 約1時間30分の講演のうち、この話に割かれた時間は20分未満です。改めて見直してみて、濃いKeynoteだったなと感じます。

AWSサービスの裏側で動いている物理的なサーバの話は、普段使っている分にはほとんど意識しなくて良い部分のため、こうして詳しく説明を聞くと新鮮で面白かったです。

私はオンプレの仮想化環境(VMWareやOpenstack)には長く親しんだ経験があるのですが、AWSともなるとやはり次元が違うなあという感想です。 ハードウェアにもマイクロサービスの考えを取り入れよう、というのは取り分け斬新に思いますし、パフォーマンスを高めると同時にセキュリティも高めてる点はさすがとしか言いようがありません。 ユーザに高いレベルのサービスを提供しようというその姿勢は見習いたいものだと思いました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.